Pular para o conteúdo principal

Controle MQTT programado

dica

O controle MQTT agendado é destinado a mensagens programadas com antecedência. Para controle ao vivo, veja Controle MQTT Ao Vivo em vez disso.

Este guia ajudará você a configurar o MQTT em seu SmartgridOne Controller para controlar e monitorar remotamente instalações de baterias e painéis solares.

O que você precisa

  1. SmartgridOne Controller com conectividade à internet.
  2. Credenciais MQTT: Isso pode ser solicitado enviando um e-mail para support@eniris.be.
  3. Ambiente de desenvolvimento Python (ou qualquer outro cliente MQTT). Este guia usa um exemplo básico escrito em Python para ajudá-lo a iniciar com o MQTT e enviar comandos. Recomendamos o uso do Python pela facilidade de uso, mas qualquer outro cliente MQTT é suportado.

Informações adicionais

O MQTT é um protocolo de comunicação rápido pela internet. É um sistema de mensagens publicadas/assinadas, que permite uma conexão direta entre sua máquina e o SmartgridOne Controller. Seus ativos são classificados em grupos de solar, bateria, EV e HVAC. No momento, essa integração permite controle por grupo, não por dispositivo.

Configuração inicial (Ponto de partida para novos usuários)

Eu tenho um SmartgridOne Controller que gostaria de configurar para Controle Remoto MQTT.

1. Verifique sua rede

Certifique-se de que sua rede permite tráfego de rede mqtt pela porta 1883. Você pode fazer isso usando o comando:

nc -zv mqtt.eniris.be 1883

Quando este comando não estiver disponível, você pode alternativamente baixar e executar este código python.

Em caso de dúvida, consulte seu engenheiro de rede ou use temporariamente o hotspot 4G/5G do seu telefone quando ocorrerem erros de conexão.

nota

Quando a porta 1883 não estiver acessível a partir da sua rede, oferecemos um backup na porta 80. Isso pode ser configurado no seu cliente MQTT em um passo posterior neste manual.

2. Adicione seus dispositivos

Faça login na interface de comissionamento e certifique-se de que os dispositivos estão adicionados ao SmartgridOne Controller.

3. Adicione o sinal externo MQTT

Imagem 1
Imagem 1
Imagem 1

4. Ative o sinal remoto MQTT

Selecione todos os dispositivos que você gostaria de incluir no Controle Remoto MQTT.

Imagem 1

5. O sinal remoto foi adicionado

A interface de Controle Remoto MQTT foi agora ativada no SmartgridOne Controller.

Estamos agora prontos para enviar alguns comandos básicos usando um exemplo simples. A coluna Status indica se algum comando está ativo.

Script de demonstração em Python

Um bom ponto de partida seria testar sua nova integração com um exemplo simples.

Este código de teste faz um trabalho simples de enviar continuamente o seguinte cronograma:

  • Bateria: Carregar a 5 kW por 15 minutos em 10 minutos
  • Solar: Definir potência para 0 kW por uma hora em 30 minutos

O SmartgridOne Controller responde com uma mensagem de confirmação contendo o identificador único do cronograma ou uma mensagem de erro.

Em seguida, buscamos o próximo cronograma para ambos os tipos de dispositivo, confirmando que o comando foi bem-sucedido.

Por favor, baixe o arquivo abaixo em seu IDE Python preferido. Preencha seu número de série e credenciais MQTT e execute o script:

Quando o acima for bem-sucedido, você pode continuar enviando outros tipos de mensagens. Todas as mensagens estão descritas abaixo.

Documentação MQTT para Envio de Comandos

Esta seção detalha o formato de mensagem MQTT e os requisitos de payload para configurar o controle agendado de dispositivos dentro da rede do SmartgridOne Controller.

Tópicos MQTT

  • Tópico de Inscrição: standard1/rp_one_s/remoteScheduleMetrics/<controller SN>
  • Tópico de Feedback: standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>

Onde <controller SN> deve ser substituído pelo número de série real do SmartgridOne Controller que você pretende controlar.

Tipos de Mensagens MQTT

1. Definir Cronograma (set_schedule)

Cria um novo cronograma para um tipo de dispositivo.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "set_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcional),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Policy>",
"power_setpoint_w": <Setpoint em watts>,
"replace_overlap": <True/False> (Opcional) (default=False)
}
}

Resposta (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedule_ack",
"state": {
"schedule_id": <Schedule ID>,
"deleted_ids": <Schedule IDs deletados se replace_overlap=True>
},
"responseCode": 0
}
}

2. Obter Cronograma (get_schedule)

Recupera um cronograma específico pelo ID.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedule",
"fields": {
"id": <Schedule ID>
}
}

Resposta:

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

3. Obter Cronograma Ativo (get_active_schedule)

Recupera o cronograma atualmente ativo para um tipo de dispositivo.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_active_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcional)
}
}

Resposta (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

4. Obter Próximo Cronograma (get_next_schedule)

Recupera o próximo cronograma programado para um tipo de dispositivo.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_next_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcional)
}
}

Resposta (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

5. Obter Cronogramas (get_schedules)

Recupera todos os cronogramas para uma data específica.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<Date String of Format dd/mm/yyyy>"
}
}

Response (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

6. Obter Programações Futuras (get_future_schedules)

Recupera todas as programações futuras.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_future_schedules",
"fields": {}
}

Response (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_future_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

7. Remover Programação (remove_schedule)

Remove uma programação específica por ID.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "remove_schedule",
"fields": {
"id": <Schedule ID>
}
}

Response (Sucesso):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "remove_schedule_ack",
"state": "Programação <Schedule ID> removida com sucesso",
"responseCode": 0
}
}

8. Obter Feedback do Site (get_feedback)

Recupera feedback detalhado sobre o estado do sistema.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {}
}

Response (Sucesso):

Estrutura do Payload de Feedback

Formato Padrão de Resposta de Programação

{
"id": <Schedule ID>,
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Opcional),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Schedule Policy>",
"power_setpoint_w": <Setpoint em watts>,
"created_at": <Unix Timestamp>
}

Tipos de Componentes e Políticas

Para detalhes sobre os componentes disponíveis e políticas que podem ser programadas, consulte a seção Componentes e Políticas MQTT na documentação de Controle MQTT ao Vivo.

Programações específicas de dispositivos podem ser enviadas usando o campo opcional node_id, referindo-se ao ID do nó do dispositivo controlável.

Tratamento de Erros

Todas as mensagens podem retornar uma resposta de erro com responseCode: 1 quando um erro ocorre:

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "<Message Type>_ack",
"error": <Error Body>,
"responseCode": 1
}
}

Quando um erro não relacionado ocorre, o tipo de mensagem será (general_error).

Os erros comuns incluem:

  • Sobreposição de programação com programações existentes
  • Faixa de tempo inválida
  • Tipo de dispositivo não encontrado
  • ID de programação não encontrado
  • Política inválida para tipo de dispositivo

Regras de Gerenciamento de Programações

  1. Regras de Sobreposição
    • Programações não podem sobrepor para o mesmo tipo de dispositivo
    • Programações não podem sobrepor para o mesmo dispositivo
    • Programações para o mesmo dispositivo e tipo de dispositivo não podem sobrepor
    • Programações existentes que se sobrepõem serão excluídas se a variável replace_overlap estiver definida como True ao criar uma nova programação.
  2. Cada programação deve ter:
    • Um tipo de dispositivo válido
    • Um horário de início (timestamp Unix)
    • Um horário de término (timestamp Unix)
    • Uma política (correspondendo às políticas disponíveis do tipo de dispositivo)
    • Um setpoint de potência (para políticas que exigem)
  3. O horário de início deve ser anterior ao horário de término
  4. O horário de início deve ser pelo menos cinco minutos no futuro
  5. Programações só podem ser excluídas se começarem pelo menos cinco minutos no futuro
  6. Programações podem ser definidas para diferentes tipos de dispositivos independentemente
  7. O sistema aplica automaticamente a política apropriada quando uma programação se torna ativa